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I n the previous article {Smalltalk Report, September, p. 4), 
we introduced a point-and-clickruleeditorthat manip¬ 
ulates the ProgramNode tree. We continue to investigate 
how it works. 

TYPING 

The tool's type system is based on the types as sets of 
classes approach used by Graver and Johnson. 1 ' 2 A 
ProgramNodeType is defined as a set of zero or more 
ProgramNodeTypeOptions. A ProgramNodeTypeOption has a class 
name and a taxonomy. Taxonomy indicates whether an 
exact match with the cl ass i s requ i red (i sM ember) or whether 
a subclass can also be used (isKind). For example, a type 
option for Boolean or Number has the isKind taxonomy 
because these are abstract classes. The ProgramNodeType is 
depicted with angle brackets, with a vertical bar between 
options, as in <ByteSymbol | (kindOf: Number)>; the vertical 
bar is read asor. If kindOf>is notated, thetaxonomy isisKind: 
otherwise, it is isMember. 

A type can be said to satisfy another type. For example, 
<ki ndOf: Number> is satisfied by <lnteger>; and <ByteSymbol | 
ByteString> is satisfied by <ByteSymbol>. Two types can be 
merged by adding their unique typeoptions. 

There are two special types, s’Anything^and s'Noth ing'>. 
kAnything's-isshorthandfor<kindOf: Objects<'Nothing'>has 
zero options and is used exclusively for either an out-of- 
scope condition, or for an unknown type inside a 
nonevaluated block. To illustrate: 

[: aBoolean | | tl | 
tl :='abc'. 

tl "<'Nothing'>out-of-scope" : = aBoolean 
ifTrue: [^123] 
ifFalse: r#xyz]]. 

[ I tl | 
tl :='abc'. 

[tl "<'Nothing’> non-evaluated-block"]] 

Selector Information. One of the MorphConstructs a 
MessageNodeWrapper knows how to perform isChangemes- 


sageselector and arguments only (123 + 456->123* nil). The 
user is usually presented with a set of this construct, with 
each element of the set having selector information that 
includes the selector, argument types (if any), and the 
return type. Where does this set of selector information 
come from? 

For a given typeoption of the receiver, if the type-option’s 
class is not a business object, the information comes from 
hardcoded information on the base classes; otherwise it is 
generated from the business-object’s logical-schema 
attri bute/ type specifi cati on. The set of selector i nformati on 
presented to the user is the intersection of sets from all the 
type options; therefore, for distant options this may mean 
selector information from Object only. 

Let’s say the selection is a MessageNodeWrapper of receiv¬ 
er Smalll nteger, for example, 123 isNil. The receiver knows 
its type (<SmalII nteger>), so we ask the class, whose name 
we get from the single type option, for selector informa¬ 
tion. This information will come from Smalll nteger class 
and its superclasses. 

This is an example of selector information from the 
class side of Number: 

'TypedSelector 

singleArgumentSelector: #< 
receiverRequiredType: ProgramNodeType number 
argumentType: ProgramNodeType number 
returnType: ProgramNodeType boolean 

The selector, required type for receiver, required type for 
argument, and return type are all specified (via an instance 
of class TypedSelector). Selector information is inherited 
and can be overridden. It isspecified for operators of those 
base classes which are used as business-object attribute 
types (e.g. Boolean, ByteString, Number). 

OTHER TYPE OPTIONS 

ProgramNodeTypeOption lives in a hierarchy: 

AbstractProgramNodeTypeOption 

ReifiedBlockValueTypeOption (argumentlndex) 
ProgramNodeTypeOption (className, taxonomy) 
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BlockClosureTypeOption (valueType, 
argumentTypes) 

HomogeneousCol lectionTypeOption 
(elementType) 

HomogeneousColIectionTypeOption describes a homoge¬ 
neous collection, meaning all elements have the same 
elementType. Homogeneous can be very flexible, as the 
type can be <'Anything’>, for example. This type option 
takes selector information from the instance side, as well 
as the class side. An instance of the collection is created 
and given one element: a copy of elementType. 

Here’s an example of selector information from the 
instance side of Col lection: 

'TypedSelector 

singleArgumentSelector: #select: 
receiverRequiredType: (ProgramNodeType 

homogeneousCollectionOfName: self class name 
elementType: self first copy) 
argumentType: (ProgramNodeType 

blockClosureSingleArgument: self first copy 
valueType: ProgramNodeType boolean) 
isArgumentPrototyping: true 
blockArgu mentEval uator: 

MessageWrapperBlockArgu mentEval uator nothingOrLoop 
returnType: (ProgramNodeType 

homogeneousCollectionOfName: self class name 
elementType: self first copy) 

The argument of the #select: message is specified as a 
block whose si ngle argument is a copy of elementType. The 
return type is specified as a collection of this type. Note 
that this selector information specifies using a prototype 
argument; that is, the argument instead ofbeingnil will be 
ablockwith an argument of the correct type. 

ReifiedBlockValueTypeOption is used to determine the 
return type of a message. Here’s the selector information 
for #ifTrue: from the class side of Boolean: 

TypedSelector 

singleArgumentSelector: #ifTrue: 
receiverRequ iredType: ProgramNodeType boolean 
argumentType: (ProgramNodeType 
blockClosu reNoArgumentsAndValue: 

ProgramNodeType anything) 
isArgumentPrototyping: true 
blockArgu mentEval uator: 

MessageWrapperBlockArgumentEvaluator onOrOff 
returnType: (ProgramNodeType options: 
(OrderedCollection 

with: ( ReifiedBlod<\felueTypeOption onArgumentlndex: 1) 
with: ProgramNodeTypeOption nil)) 

This states that the return type for #ifTrue: consists of type 
options for nil, and for the value of the block expected as 
the message’s fi rst argu ment. For example, the type of mes¬ 
sage aBoolean iff rue: [123] is <UndefinedObject | Smalll nteger>; 
foraBoolean ifTrue: [‘abc’], it is <UndefinedObject | ByteString>. 


TRAVERSAL OF THE WRAPPER TREE 

Traversal of the wrapper tree yields valuable information 
such as node-wrapper type. Traversal isdonein postorder 
fashion. 

A wrapper knows the order in which to traverse its chil¬ 
dren. For example, A MessageNodeWithArgumentsWrapper has 
the child traversal order: {receiver, argument-collection}. 

The Block Evaluator. If at least one of the argu ments of a 
MessageNodeWithArgumentsWrapper is a block defined (via 
selector information) as potentially evaluating, we 
append pseudo-child MessageWrapperBlockArgument 
Evaluator to the chi Id traversal order (pseudo in the sense 
that the MessageNode itself has no such child). The evalu¬ 
ator serves to simulate evaluation of a block by travers¬ 
ing it. Without the evaluator, the BlockNodeWrapper is 
treated as a leaf wrapper and is not traversed. The evalu¬ 
ator poses as having the block-argument grandchildren 
of its parent, as its own children. 

The evaluator is defined with a collection of 
EvaluationMetaSpecs. An EvaluationMetaSpec is a descrip¬ 
tion for one step through of the method specified i n the 
message. This spec is used to produce a collection of 
child traversal orders. An EvaluationMetaSpec, in turn, is 
defined with a collection of ArgumentMetaSpecs. The 
ArgumentMetaSpec states whether the block argument is 
optional, and whether it is possibly a looping block; 
this spec is identified by the message-argument index. 

For example, here is Boolean »i fTrue: 
ifFalse: with its two EvaluationMetaSpecs: 

• {required, noLoop, index 1} 

• {required, noLoop, index 2} 

The ifTrue: argument is the first argument of the message, 
and thus is designated by index 1 ; the ifFalse: being the 
second isdesignated by inde< 2. These EvaluationMetaSpecs 
produce the two traversal orders: {{l},-{2}}; in other words, 
we must either evaluate the first message argument, the 
ifTrue: block; or else we must evaluate the second mes¬ 
sage-argument, the ifFalse>block. 

Here is Co I lecti o n »detect: ifNon e: with its two 
EvaluationMetaSpecs: 

• {required, loop, index 1} 

• {optional, loop, index 1}, {required, 

noLoop, index 2} 

We either loop one or more times evaluating the detect: 
block or we possibly loop one or more times evaluating 
the detect: block, followed by definitely evaluating the 
ifNone: blockonce. 

BRANCHING ATTHE EVALUATOR 

The evaluator always terminates the current traversal. 
The result for the evaluator is obtai ned by branchi ng new 
traversals and combining the results; each child traversal 
order of the evaluator produces another branch. 

Let’s find a block’s valuetype. 

[2 even 
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EXTERNALIZING BEHAVIOR 


tl: = 123. 
t2 : = 'abc'. 
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Figure9. Branching. 


ifTrue: ["123] 
ifFalse: [‘abc’]. 

#xyz] "what is value-type for the block?" 

We start at the first terminal node wrapper of the block 
and perform a forward traversal on the lookout for either 
a ReturnNodeWrapper or the very last statement of the 
block. We eventually arrive at the evaluator and pro¬ 
ceed to find its result, which in this case will be our 
answer. Because the evaluator has two child traversal 
orders, it branches two traversals. We take the first tra¬ 
versal and find a ReturnNodeWrapper of type 
<Smalllnteger>. The second takes us past the confines of 
the ifFalse: block. We visit a MessageNodeWithArgu- 
mentsWrapper, the final outer block statement and stop 
with a type of <ByteSymbol>. We combine the results to 
get our answer of <Smal II nteger | ByteSymbol >. This traver¬ 
sal is depicted in Figure 9. The first branch occurs in vis¬ 
itations 8.lx shown in dark grey; the second, in 8.2x 
shown in light grey. Note that although 2 even is always 
true, the tool is unaware of this. 

Looping. Let’s look at type inferencing for a temporary 
variable. Let’s find the type of t2 in the final statement of: 

[: al | | tlt2t3 | 


al myCollection 
detect: [: a2 | 
t3 : = tl. 
tl : = $a. 
t2 : = t3] 
ifNone: [nil], 
t2 "what is my type?” ] 

If we don’t loop at all, t2 type = 
<ByteString>; if we make one pass, t2 type 
= <Smalllnteger>; if we make two passes, 
t2 type=<Character>. Thus, results differ 
depending on the number of times the 
detect: block istraversed. 

The EvaluationMetaSpecs generate the 
appropriate child traversal orders, 
based on the number of descendent 
assignment statements (excluding 
those found in child block descen- 
dents). Each assignment generates 
another child traversal order. In the 
example, we find three assignments 
in the detect: block. The first 
EvaluationMetaSpec for #detect:ifNone: 
therefore generates {{1}, {1,1}, {1,1,1}}, 
and the second generates {{2}, {1,2}, 
{1,1,2}, {1,1,1,2}}. (We play it safeto loop 
the maximum amount, even though in 
this case only two passes are needed.) If 
we had no assignments, the resulting 
child traversal orders would simply be 
{{1}} from the first spec, and {{2}, {1,2}} 

from the second. 

This brute-force technique isof exponential order, but 
this is not a concern for minimal branching. The standard 
technique for type inferencing uses polynomial-order 
symbolic-execute via solution of equations. 3 

Type i nferenci ng for a temporary variable i nvol ves travers¬ 
ing the wrapper tree backwards from the VariableNodeWrapper. 
Let’s fi nd the result for a double pass by walki ng the chi Id tra¬ 
versal order {1,1} branch of the #detect:ifNone: evaluator. As 
shown in Figure 10, we proceed backwards on the lookout for 
AssignmentNodeWrappers with VariableNodeWrapper t2, and eventu¬ 
ally reach the detect: blocks third statement and stop at the 
AssignmentNodeWrapper. The result of the AssignmentNodeWrapper 
isthetypeofitsrighthand side, VariableNodeWrapper on t3.Sowe 
trigger a new traversal for inferenci ng the type of t3 (shown in 
dark grey), but the technique is to conti nue usi ng the current 
child traversal order oftheevaluator. This new traversal inturn 
triggers another for inferencing the type of tl (shown in light 
grey), again keeping the child traversal order. We know to tra¬ 
verse the detect: block once more, and find type tl to be 
Characters 

TREATMENT OF BLOCKS 

The contents of a block are treated as live, whether the 
block is evaluated or not. This is not an oversight, but a 
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Figure 10. Looping. 


necessity. Remember that the rule block itself isdead ifitis 
not being evaluated; surely we want this type checked, as 
this is the whole poi nt. Li kewise for any descendent block. 

Also, remember that due to the morphing process, 
what is currently not a block can perhaps be morphed to 
a block's first statement, and vice versa (construct Enclose 
statement in block (123^ 123]) and construct Return 
block's first and only statement ([ 123]->T23)). 

Traversal beyond the confines of a block depends on 
the situation. If the block is a statement, then there is no 
traversal beyond it. If the block is a message argument, 
then it depends on the block evaluator EvaluationMetaSpec 
acknowledging the block. Even if the block evaluator 
knows that a given block is never evaluated, the contents 
of the block are treated as fully viable (e.g., if the user 
selects inside the block); if it is not evaluated we simply 
don't traverse past the confines of the block. (An unknown 
type in this situation is defined as <"Nothing'> as dis¬ 
cussed). Currently, all block-evaluator EvaluationMetaSpecs 
have live blocks 

CREATION OFTHEWRAPPERTREE 

Creation of the wrapper tree occurs on string input to 
the tool, as wel I as acceptance of text from the Freestyle 
text view. The creation is achieved in iterative fashion, 
using forward traversal, during which we force our¬ 


selves into blocks in order to traverse 
them. 

The MessageNodeWrapper does the main 
job. It fi nds the appropriate selector i nfor- 
mation based on the type of its receiver. 
From this information, the required types 
of its arguments are instated, as well as 
the type of the message itself. 

Validation is performed, ensuring that 
a wrapper conforms to syntax and the 
limitations of the tool. For example, a 
ReturnNodeWrapper ensures that it is last in 
a sequence of statements, and an 
AssignmentNodeWrapper ensures that its 
value child is not a BlockNodeWrapper. A 
faulty wrapper is highlighted in the 
Freestyle text view along with the appro¬ 
priate error. 

CONCLUSION 

Eagle needed a rule language, and 
Smalltalk itself was chosen. A point-and- 
click rule editor was developed that con- 
strains the user to produce valid syntax 
with valid message selectors, via selec¬ 
tion of valid ProgramNode tree manipula¬ 
tions. The user is responsible for valid 
message arguments by selecting from 
manipulations that satisfy type require¬ 
ments. State and behavior wrapped 
around the ProgramNode tree make it type 
aware and traversable. 

Can such a tool be generalized for editing Smalltalk in 
general? Probably not. Several issues would quickly get 
out of hand, such as specifying and maintaining selector 
information for all selectors. But for a rule language sub¬ 
set, the tool has a niche. S 
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Figures 9 and 10 inadvertently ran as Figures 6 and 7 in part 1 
of this article in September. We apologize for any confusion. 
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